kexec: limit scope of the use of compat_kexec_range_t
authorKeir Fraser <keir.fraser@citrix.com>
Thu, 28 Feb 2008 10:45:47 +0000 (10:45 +0000)
committerKeir Fraser <keir.fraser@citrix.com>
Thu, 28 Feb 2008 10:45:47 +0000 (10:45 +0000)
commit2b982798afc5a3184851cdecc87d12511b58746d
treee90c093f9b798bb7b9a0bc21060d6dc927bd1596
parent081d18a09a3afe9f3f4c3c6ae7d4219b71f71b7e
kexec: limit scope of the use of compat_kexec_range_t

Unless I am mistaken, the compat functions are provided a stable ABI.
This includes providing a stable version of xen_kexec_range_t in the
form of compat_kexec_range_t.  However, internally it doesn't really
matter how xen represents the data.

Currently the code provides for the creation of a compat version of
all kexec range functions, which use the compat_kexec_range_t
function. This is difficult to extend if range code exists outside of
xen/common/kexec.c.

The existence of "#ifdef CONFIG_X86_64" in the code suggests that some
of the range code might be better off in architecture specific code.
Furthermore, subsequent patches will introduce ia64-specific range
handling code, which really would be much better off somewhere in
arch/ia64/.

With this in mind, the handling of compat_kexec_range_t is changed
such that the code which reads and returns data from user-space
translates between compat_kexec_range_t and xen_kexec_range_t.  As,
padding aside, the two structures are currently the same this is quite
easy. Things may get more tricky in the future, but I don't believe
this change is likely to make things significantly worse (or better)
in that regard. In any case, refactoring can occur again as required.

Signed-off-by: Simon Horman <horms@verge.net.au>
xen/common/compat/kexec.c
xen/common/kexec.c